Interesting. I wonder if preload scales well, or whether at some point with enough code we'll have a noticeable startup delay due to code compilation. It may be possible to store them in the binary as compiled opcodes, with the file cache mechanism.

I would be in favor of this.
I wonder how performance compares between native and php in the array_find test when the closure takes 2 args, on your machine (to avoid extra arg copy overhead).
Also note on Windows we don't have preloading.

With a 2 args closure, native is faster (1.04 times).
With JIT this branch is 2.24 times faster.

Unsurprisingly, I'm also in favor of this for the maintenance aspect alone. However as a long-term goal I would find it important to be able to mix and match native and userland methods within a single class, similarly to Java’s native methods.

As an example, SensitiveParameterValue could be mostly implemented in userland code, but it currently has some internals-only behavior (get_properties_for) to hide the values in cases where __debugInfo() is insufficient, e.g. when casting to (array).

For the implementation I would therefore be in favor of putting the implementation right into the stub files and to indicate somehow if the function / method is a stub or whether it contains the implementation. That would also allow downstream consumers to use the stub-files as-is.

We have got issue with preloading and FPM using multiple pools with different user / groups and then using permissions for some operations so this would need to be properly tested. There is currently an ugly hack for single user but if there are multiple different users, then it might not work - I haven't tested it for some time but there were issues around it.

Well this setup has already issues with opcache (clearing locks), just wondering if basically required preloading could make it even worse.

@bukka @nielsdos yes, I used opcache.preload for demonstration purposes here, but a proper implementation would not use opcache.preload or depend on Opcache. There are a few possibilities, such as compiling during startup (without changing uid) and moving op arrays to the native heap, or compiling at build time as @iluuu1994 suggested.

As an example, SensitiveParameterValue could be mostly implemented in userland code, but it currently has some internals-only behavior (get_properties_for) to hide the values in cases where __debugInfo() is insufficient, e.g. when casting to (array).

Is it feasible to integrate C and PHP through JITed FFI (#14491) to address these types of issues

As only php user without much low-level understanding of the php engine I see that this effect was possible due to "inlining"

because JIT is able to inline the callback into array_find()

because native C implementation would still use its C calls and introduce some overhead.

So to leverage this approach some condition must be met:

• JIT enabled
• Enough hot paths executed so the code gets jitted, but the php wouldn't know if this function can leverage JIT upfront?
  it's managed by those ini settings, right?

opcache.jit_hot_loop = 64
; After how many iterations a loop is considered hot. ...
opcache.jit_hot_func = 127
; After how many calls a function is considered hot ...

I tried to do some research and have a couple of follow-up questions:

1. Is it feasible to add in php something like @ForceInline form JVM or [MethodImpl(MethodImplOptions.AggressiveInlining)] from C# ?

2. Maybe we could write a userland code like belove?

#[JIT]
function array_find(array $array, callable $callback): mixed {
    foreach ($array as $key => $value) {
        #[JIT] // We don't know if callback can be inlined here
        if ($callback($value, $key)) {
            return $value;
        }
    }
}

3. Would such an attribute need to annotate both the caller and the callback?
4. Some callbacks due to their complexity, bindings, or dependencies can't be jitted at all?

#[JIT]
$cb = static function ($item) {
            return $item === 5000;
    }

I guess this may cause a question if we should start using this everywhere. Like this one: https://www.reddit.com/r/csharp/comments/8mw0w9/should_i_spam_all_my_methods_with/

On the other hand, if PHP ever supported a force-inlining hint, tools like static analyzers or IDEs could automatically recommend adding it to trivial methods and functions.

Frameworks could include it into their code like Laravel’s helpers https://laravel.com/docs/12.x/helpers

It could become as common as the “leading slash” global function import optimization (is_array → \is_array)